Electronic form user interfaces

ABSTRACT

A system and method validating entry of data into a structured data file in real-time is described. The system and method also described a real-time validation tool that enables a developer to create custom validation rules. These custom validation rules can include preset validation rules, which the real-time validation tool enables a developer to create in an easy-to-use way.

RELATED APPLICATIONS

This is a divisional application of, and claims priority to U.S. patentapplication Ser. No. 10/402,640, the disclosure of which is incorporatedby reference herein.

BACKGROUND

Extensible markup language (XML) is increasingly becoming the preferredformat for transferring data. XML is a tag-based hierarchical languagethat is extremely rich in terms of the data that it can be used torepresent. For example, XML can be used to represent data spanning thespectrum from semi-structured data (such as one would find in a wordprocessing document) to generally structured data (such as that which iscontained in a table). XML is well-suited for many types ofcommunication including business-to-business and client-to-servercommunication. For more on XML, XSLT (eXtensible Style-sheet LanguageTransformation), and XSD (schemas), the reader is referred to thefollowing documents which are the work of, and available from the W3C(World Wide Web consortium): XML Schema Part 2: Datatypes; ExtensibleMarkup Language (XML) 1.0 second edition specification; XML Schema Part1: Structures; and XSL Transformations (XSLT) Version 1.0.

Before data can be transferred, however, it must first be collected.Electronic forms are commonly used to collect data. Electronic formscollect data through data-entry fields, each of which typically allows auser to enter data. Once the data is received, it can be stored in anXML data file. The data from a particular data-entry field typically isstored in a particular node of the XML data file.

Users often enter invalid data into data-entry fields, however. Invaliddata, when stored in a data file, can misinform people and causeunexpected behavior in software relying on the data file. Because ofthis, businesses and individuals expend extensive time and effort toprevent invalid data from making its way into XML data files.

One such way to help prevent invalid data from corrupting an XML datafile is to validate the data before the data file is saved or submitted.By validating the data file before it is saved or submitted, invaliddata can be corrected before it is permanently stored in the data fileor used by another application. Validation typically is performed when auser attempts to submit or save the entire form, and is thus performedon a group of individual data fields at one time.

One of the problems with this manner of validating data is that the userreceives a list of errors disjointed from the data-entry fields fromwhich the errors arise. These errors may be difficult to relate back tothe data-entry fields in the electronic form, requiring users to huntthrough the data-entry fields to find which error from the list relatesto which data-entry field in the electronic form.

Another problem with this manner is that even after the user determineswhich error from the list relates to which data-entry field, the usermay have to expend a lot of effort to fix the error if the errornotification is received well after the user has moved on. Assume, forexample, that the user has entered data from a 400-page source documentinto ninety-three data-entry fields. Assume also that once finished, theuser attempts to save or submit the electronic form. A validationapplication then notifies the user of sixteen errors. After finding thatthe first error relates to the eleventh data-entry field out ofninety-three, the user will have to go back through the 400-pagedocument to find the data that he or she was supposed to correctly enterinto the eleventh data-entry field. This manner of validation canrequire extensive hunting through large or numerous source documents tofix old errors, wasting users' time.

Even worse, the validation application may return only the first of manyerrors. For this type of validation application, a user has to go backand fix the first error and then re-save or re-submit. If there are manyerrors in the electronic form—as is often the case—the user must go backand fix each one separately before re-saving or re-submitting to findthe next error. If there are even a few errors, this process can take alot of time.

Another problem with this process is that if the user submits theelectronic form to a server, it taxes the server. A server can be sloweddown by having to validate electronic forms, reducing a server's abilityto perform other important tasks.

In addition to these problems, the current way of validating data forstructured data files can allow some data that is not desired. Whilethis allowance of undesired data can sometimes be prevented, doing socan require extensive time and sophisticated programming abilities.

For these reasons, validation of data for XML data files can require alot of a data-entry user's time and tax servers. In addition, without askilled programmer expending considerable effort, significant amounts ofundesired data can get through.

SUMMARY

In the following description and figures, a real-time validation tool isdisclosed. This real-time validation tool notifies a user of an error asit is entered into a structured data file's electronic form.

In another implementation, the real-time validation tool enables adeveloper to create custom validation rules for use by the real-timevalidation tool.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates a system with a display screen, computer, anduser-input devices. The system implements a method for validating datafor structured data files.

FIG. 2 illustrates an exemplary screen display showing a blankelectronic form having data-entry fields.

FIG. 3 is a flow diagram of an exemplary process for real-timevalidation of data for a structured data file.

FIG. 4 illustrates an exemplary screen display showing an electronicform with a filled-in data-entry field.

FIG. 5 illustrates an exemplary screen display showing an electronicform with a data-entry field having an invalid entry.

FIG. 6 illustrates an exemplary screen display showing an electronicform with a data-entry field having a modeless invalid entry and adialog box.

FIG. 7 illustrates an exemplary screen display showing an electronicform with a data-entry field having a modal invalid entry and a dialogbox.

FIG. 8 illustrates an exemplary screen display showing an electronicform having many filled-in data-entry fields, one of which contains amodal invalid entry, and a dialog box.

FIG. 9 is a flow diagram of an exemplary process for adding validationrules for use by a real-time validation tool.

FIG. 10 illustrates an exemplary custom validation screen, including adevelopment copy of an electronic form and a properties box.

FIG. 11 illustrates an exemplary custom validation screen, including adevelopment copy of an electronic form, a properties box, and avalidation option box.

FIG. 12 illustrates an exemplary custom validation screen, including adevelopment copy of an electronic form, a properties box, a validationoption box, and a preset validation selection box.

FIG. 13 illustrates an exemplary custom validation screen, including adevelopment copy of an electronic form, a properties box, a validationoption box, and a preset validation selection box.

FIG. 14 illustrates an exemplary custom validation screen, including adevelopment copy of an electronic form, a properties box, a validationoption box, a preset validation selection box, and a node selection box.

FIG. 15 illustrates an exemplary custom validation screen, including adevelopment copy of an electronic form, a properties box, a validationoption box, and a preset validation selection box.

FIG. 16 illustrates an exemplary custom validation screen, including adevelopment copy of an electronic form, a properties box, a validationoption box, and a preset validation selection box.

FIG. 17 illustrates an exemplary custom validation screen, including adevelopment copy of an electronic form, a properties box, and avalidation option box.

FIG. 18 illustrates an exemplary script entry screen for entry of ascript-based validation rule.

FIG. 19 is a block diagram of a computer system that is capable ofsupporting a real-time validation tool.

The same numbers are used throughout the disclosure and figures toreference like components and features.

DETAILED DESCRIPTION

The following disclosure describes an easy and intuitive way for a userto correctly edit structured data files by notifying the user of hererrors as she makes them. As a user enters data into a data-entry fieldof an electronic form, a real-time validation tool validates the data toensure that the data is valid. If the data is valid, the user cancontinue on to the next data-entry field. If the data is not valid, thereal-time validation tool may allow the user to continue on or may not,depending on the error. The real-time validation tool, whether it allowsthe user to continue or not, does not allow the user to output the datainto a structured data file until it is valid.

The following disclosure also includes a description of a way for adeveloper to create custom validation rules for use by the real-timevalidation tool. The real-time validation tool uses validation rules todetermine when data entered is valid or invalid. A developer can adjustor add new rules for use by the real-time validation tool. A developercan, for instance, add a validation rule, set whether a user cancontinue or not if the rule is violated, decide what information isprovided by the real-time validation tool to the user when the rule isviolated, and determine how these are done.

Creating custom validation rules will be discussed in greater detail inthe later parts of the detailed description. The earlier parts willfocus more on a how the real-time validation tool validates data fromthe perspective of a user.

For discussion purposes, the real-time validation tool is described inthe context of a single computer, user-input devices, and a displayscreen. The computer, display screen, and user-input devices will bedescribed first, followed by a discussion of the techniques in whichthese and other devices can be used.

Exemplary Architecture

FIG. 1 shows an exemplary system 100 used to facilitate real-timevalidation of structured data files. This system 100 includes a display102 having a screen 104, user-input devices 106, and a computer 108.

The user-input devices 106 can include any device allowing a computer toreceive a developer's input, such as a keyboard 110, other device(s)112, and a mouse 114. The other device(s) 112 can include a touchscreen, a voice-activated input device, a track ball, and any otherdevice that allows the system 100 to receive input from a developer. Thecomputer 108 includes a processing unit 116 and random access memoryand/or read-only memory 118 including applications, such as an operatingsystem 120 and a real-time validation tool 122, which includes a userinterface 124. The computer 108 communicates with a user and/or adeveloper through the screen 104 and the user-input devices 106.

The real-time validation tool 122 facilitates real-time validation ofdata for structured data files and is executed by the processing unit116. The real-time validation tool 122 is capable of validating dataentered into an electronic form as it is being entered by a user. Thus,with each new piece of data entered, the real-time validation tool 122can check whether or not that data is valid and respond accordingly.

The real-time validation tool 122 can respond by informing the user ofinvalid data and allowing or not allowing the user to continue editingthe electronic form. If the real-time validation tool 122 stops the userfrom continuing on to the next data-entry field, it alerts the user ofthe error. To make the error easy to fix, the real-time validation tool122 can inform the user information about the error, such as why thedata entered is incorrect or what type of data is correct. The real-timevalidation tool 122 can alert the user through an alert containinginformation, such as a dialog box in a pop-up window, or graphics, suchas a colored box encasing the data-entry field, or in other ways, likerolling back the data in that data-entry field or keeping the user'scursor in the data-entry field. These and other ways of notifying theuser and controlling the user's actions are designed to make the user'sentry and correction of data as easy and intuitive as possible.

The real-time validation tool 122 can also allow the user to continueafter entering invalid data. In many cases, stopping the user fromcontinuing on to the next data-entry field is counterproductive. Theuser may not yet have the correct data, or may find it easier to comeback to fix all his errors at once, rather than as-he-goes. Thereal-time validation tool 122 does, however, notify the user that thedata entered into that data-entry field is invalid. By so doing, thereal-time validation tool 122 informs the user but allows the user todecide if he or she wishes to fix the error now or later. The real-timevalidation tool 122 can notify the user in various ways, such as thosediscussed above, as well as particularly un-intrusive ways, likesurrounding the data with a red, dashed-line border.

Electronic Forms, Solutions, and Structured Data Files

A view of a structured data file is depicted on the screen 104 throughexecution of the structured data file's solution. The data file'ssolution is one or more files (e.g., applications) used to enable a userto edit the structured data file, and may include logic and viewingapplications. To edit the data file in a user-friendly way, the datafile's solution contains a viewing application, such as an electronicform. This viewing application gives the user a graphical, visualrepresentation of data-entry fields showing previously entered dataand/or blank data-entry fields into which the user can enter data. Adata file typically has one solution (though solutions often containmultiple files), but each solution often governs multiple data files.

FIG. 2 shows a display screen 200 including a blank electronic form 201entitled “Expense Report”, which is generated by a solution. Thisexpense report 201 contains data-entry fields in which a user can enterdata. These data-entry fields map to a structured data file, so that thedata entered into the form can be held in the data file (and eventuallystored, once confirmed valid). They can be stored one-by-one after eachis confirmed valid, in total after all are confirmed valid and theelectronic form is submitted or saved, or in groups after each entry inthe group is confirmed valid. Data not yet stored in a data file can beheld in various locations and ways, temporarily—such as in the data file(without it being saved), or permanently—such as in an auxiliary file.

This solution presents the expense report 201 electronic form but alsocontains logic that governs various aspects of the expense report 201and the data file. In a report date data-entry field 202, for instance,the solution presents the data-entry field as a white box within a graybox, provides a description of the data desired with the text “ReportDate”, and contains logic requiring that the user enter only numbers.This logic, which can be or use a schema governing the structured datafile, can be used by the real-time validation tool 122 in validationrules used to validate data. The solution may also contain other filesused by the real-time validation tool 122 for validating data.

Validation rules are employed by the real-time validation tool 122 toensure that the right kind of data is being entered before it is storedin the structured data file. A user's business manager attempting toanalyze expenses with an expense code, for instance, would like thestructured data file to have numbers entered into an expense codedata-entry field 204. The manager may not be able to determine how anexpense should be analyzed if the expense code entered is invalidbecause it contains letters.

Each solution can be one file or contain many files, such as apresentation file or files used by the real-time validation tool 122 forvalidation rules. Files used for validation will be discussed in greaterdetail below. The presentation file is used to present or give a view ofan electronic form enabling entry of data into a structured data file,such as a visual representation of the structured data file (blank, inthis case) by the expense report 201 electronic form. In someimplementations, the presentation file is an XSLT or CSS (CascadingStyle Sheet) file, which, when applied to a structured data file writtenin XML, generates an XHTML (eXtensible Hyper-Text Markup Language) orHTML (Hyper-Text Markup Language) file. XHTML and HTML files can be usedto show a view on the screen 104, such as the expense report 201 of FIG.2.

Like solutions, structured data files can come in various types andstyles. As mentioned above, structured data files can be written in XMLor some other language. Structured data files, however, arestructured—the data they contain is oriented relative to each other.Structured data files can be modular and/or hierarchical (such as a treestructure), for instance. In a hierarchical structure, nodes of thestructured data file are designed to contain data or govern other nodesdesigned to contain data. Nodes designed to contain data can be mappedto particular data-entry fields, so that the data entered into adata-entry field is slotted for the appropriate node. Because nodes anddata-entry fields are mapped to each other, the real-time validationtool 122 can determine what node a developer or user is attempting toselect or edit when a data-entry field, rather than the node itself, isselected.

The above devices and applications are merely representative; otherknown devices and applications may be substituted for or added to thoseshown in FIG. 1. One example of another known device that can besubstituted for those shown in FIG. 1 is the device shown in FIG. 19,which will be discussed later.

Validating Data from a User in Real-Time

Overview

A system, such as the system 100 of FIG. 1, displays an electronic formwith data-entry fields to allow a user to enter data. The user can enterdata in a data-entry field and know, as he does so, whether or not thedata entered is valid or invalid. By so doing, the system 100 providesan easy, intuitive, and efficient way for a user to enter and correctdata intended for a structured data file.

FIG. 3 shows a process 300 for validating data entered into anelectronic form in real-time. The process 300 is illustrated as a seriesof blocks representing individual operations or acts performed by thesystem 100. The process 300 may be implemented in any suitable hardware,software, firmware, or combination thereof. In the case of software andfirmware, the process 300 represents a set of operations implemented ascomputer-executable instructions stored in memory and executable by oneor more processors.

Notifying a User of Errors in Real-Time

At block 302, the system 100 displays an electronic form havingdata-entry fields. The electronic form can be blank or contain filleddata-entry fields. The expense report 201 electronic form in FIG. 2 isan example of a blank electronic form.

The system 100 displays an electronic form in a manner aimed at making auser comfortable with editing the electronic form. It can do so bypresenting the electronic form with user-friendly features like thoseused in popular word-processing programs, such as Microsoft® Word®.Certain features, like undoing previous entries on command, advancingfrom one data-entry field to another by clicking on the data-entry fieldor tabbing from the prior data-entry field, cut-and-paste abilities, andsimilar features are included to enhance a user's data-entry experience.For example, the system 100 displays a blank electronic form having someof these features in FIG. 2, the expense report 201 electronic form.

At block 304, with the electronic form presented to the user, the system100 enables the user to input data into a data-entry field. The user cantype in data, cut-and-paste it from another source, and otherwise enterdata into the fields. The user can use the user-input devices 106,including the keyboard 110, the other device(s) 112 (such as a touchscreen, track ball, voice-activation, and the like) and the mouse 114.

In FIG. 4, for example, the user enters “1/27/2002” into the report datedata-entry field 202 of the expense report 201.

At block 306, the system 100 receives the data entered into thedata-entry field by the user. The system 100 receives the data from theuser through the user-input devices 106 and the user interface 124 (bothof FIG. 1). The system 100 can receive the data character-by-character,when the data-entry field is full, or when the user attempts tocontinue, such as by tabbing to move to another data-entry field. In theforegoing example, the system 100 receives “1/27/2002” from the userwhen the user attempts to advance to the next data-entry field.

At block 308, the system 100 validates the data received into thedata-entry field in the electronic form. The system 100, through thereal-time validation tool 122, analyzes the data to determine if it isvalid. The real-time validation tool 122 refers to validation rules, ifany, governing that particular data-entry field (in this example thereport date data-entry field 202). The real-time validation tool 122validates the data entered into a data-entry field without the userhaving to save or submit the electronic form. It can do so by applyingvalidation rules associated with the node of the structured data filecorresponding to data-entry field into which the data was entered.

The real-time validation tool 122 can apply validation rules from manydifferent sources. One source for validation rules is a schema governingthe structured data file. Other sources of validation rules can includepreset and script-based custom validation rules.

For script-based custom validation rules, the real-time validation tool122 enables these rules to refer to multiple nodes in a structured datafile, including nodes governing or governed by other nodes. Thus, thereal-time validation tool 122 can validate data from a data-entry fieldintended for a particular node by checking validation rules associatedwith that particular node. Through so doing, the real-time validationtool 122 can validate data entered into one node of a group with thevalidation rules governing the group of which the node is a part. Forexample, if a group of nodes contains four nodes, and is associated witha script-based validation rule requiring that the total for the data inall of the four nodes not exceed 1000, the real-time validation tool 122can validate each node against this rule. Thus, if the first nodecontains 100, the second 400, and the third 300, the real-timevalidation tool 122 will find the data intended for the fourth nodeinvalid if it is greater than 200 (because 100+400+300+200=1000). Customscript-based validation rules and preset validation rules will bediscussed in greater detail below.

In some cases the real-time validation tool 122 can build validationrules from a schema containing logic that governs a structured datafile. This logic sets forth the bounds of what data nodes in astructured data file can contain, or the structure the nodes shouldhave. Data entered into a structured data file can violate this logic,making the structured data file invalid. This invalid data may cause astructural error or a data-type error in the structured data file,possibly making the structured data file useless. To combat this, thereal-time validation tool 122 can build validation rules from astructured data file's schema.

Because structural errors are especially important, the real-timevalidation tool 122 treats these types of errors seriously. To make surethat a user treats these errors seriously, the real-time validation tool122 builds validation rules for structural errors that stop a user fromcontinuing to edit an electronic form if the real-time validation tool122 detects a structural error. Validation rules that stop the user fromcontinuing to edit the electronic form (except for fixing that invaliddata) are called modal validation rules, and errors that violate them,modal errors.

For less serious errors, such as data-type errors, the real-timevalidation tool 122 builds validation rules that do not stop the userfrom continuing. These are called modeless validation rules, and errorsthat violate them, modeless errors. Modal and modeless validation rulesand errors will be discussed in greater detail below.

To aid the real-time validation tool 122 in validating data inreal-time, validation rules are associated with particular nodes. By sodoing, with each new piece of data received, the real-time validationtool 122 is capable of comparing the data received against anappropriate list of validation rules associated with the node for whichthe data received is intended. Because this list of validation rules canbe very short for each particular node, the real-time validation tool122 has fewer validation rules to check for each piece of data enteredthan if it had to check all the validation rules for the node'sstructured data file. This speeds up the process of validation.

Continuing the previous example, at the block 308 the system validatesthe data entered, “1/27/2002”, against validation rules associated withthe report date data-entry field 202, thereby determining if the dataentered is valid.

In block 310 the system 100 determines whether to proceed to block 314or 312 depending on whether the data is valid. If the real-timevalidation tool 122 determines that the data entered is not valid, itproceeds to the block 314, discussed below. If, on the other hand, thereal-time validation tool 122 determines it to be valid, the system 100continues to block 312, allowing the user to continue editing theelectronic form. Continuing the ongoing example, if the real-timevalidation tool 122 determines that the data “1/27/2002” is valid, thesystem 100 continues on to the block 312. If not, it proceeds to block314.

At the block 312, the system 100 enables the user to input data intoanother data-entry field. In FIG. 2, for example, it would allow theuser to proceed to enter data into the expense code data-entry field 204after the data entered into the report date data-entry field 202 wasdetermined to be valid. The system 100 can allow the user to proceed toanother data-entry field as well, depending on the user's preference.

If the data is invalid, the system 100 proceeds to the block 314. At theblock 314 the system 100, through the real-time validation tool 122,determines whether to proceed to block 316 if the error is not modal and318 if it is.

Continuing the previous example, assume that the data entered into thereport date data-entry field 202 is invalid. Assume also that“1/27/2002” is not defined to be a modal error. (Modal errors are thosefor which the real-time validation tool 122 rolls back the invalid entryrequiring the user to re-enter another entry before continuing on toedit another data-entry field or requires the user to correct.) Thus, inthis example, “1/27/2002”, is invalid, but is a modeless error.

In the block 316, the real-time validation tool 122 alerts the user of amodeless error by marking the data-entry field as containing an error,but allows the user to continue editing the electronic form. To make theediting process as easy, intuitive, and efficient as possible, thereal-time validation tool 122 can mark the data-entry field from whichthe invalid error was entered in many helpful ways. The real-timevalidation tool 122 can highlight the error in the data-entry field,including with a red box, a dashed red box, a colored underline, asquiggly underline, shading, and the like. The real-time validation tool122 can also alert the user with a dialog box in a pop-up window, eitherautomatically or only if the user asks for information about the error.

The real-time validation tool 122, for example, can present a dialog boxor other presentation manner explaining the error or what type of datais required by the data-entry field. The real-time validation tool 122can present a short comment that disappears quickly or is only shown ifthe user moves his cursor or mouse pointer over the data-entry field.The real-time validation tool 122 can also provide additionalinformation on request. Many manners of showing the user that the datais invalid as well as showing information about the error can be used.These ways of notifying the user can be chosen by a developer whencreating a custom validation rule, which will be discussed in greaterdetail below.

FIG. 5, for example, shows one manner in which the real-time validationtool 122 can notify the user of an error. In FIG. 5, the expense report201 electronic form shows that the data entered into the report datedata-entry field 202 is invalid with a dashed, red-lined box surroundingthe report date data-entry field 202 (visible as a dashed, gray-linedbox).

FIG. 6 shows another example. Here, the expense report 201 electronicform shows that the data entered into the report date data-entry field202 is invalid with a dialog box 602. This dialog box can pop upautomatically or after the user requests information, such as by movinghis mouse pointer onto the report date data-entry field 202. Also inthis example, FIG. 6 shows an option for the user to gain additionalinformation about the error and/or data-entry field by selecting anauxiliary information option 604 entitled “full error description”. Ifthe user selects this option, the system 100 will present the user withmore information about the error and/or what the data-entry fieldrequires (not shown). The real-time validation tool 122 allows the userto select additional information through a tool-tips icon,right-clicking on the data-entry field, and menu commands for navigatingerrors. It can also present additional information for multiple errorsat once, such as through a list presenting information about every errorin an electronic form.

Returning to the dialog box 602, it contains error information 606. Thiserror information 606 reads: “The report date occurs before the end ofthe expense period.” This informs the user that the data entered,“1/27/2002” is invalid because it violates a rule requiring the reportdate to occur after the expense period, shown in an expense perioddata-entry field 608 as “2/3/2003”.

In some cases, if the real-time validation tool 122 determines that dataentered in a data-entry field is invalid, it will mark other data-entryfields. This is because another data-entry field may actually containthe invalid data. In FIG. 6, for example, the real-time validation tool122 marked the data entered into the report date data-entry field 202(“1/27/2002”) as invalid because it was prior to the date entered intothe expense period data-entry field 608 (“2/3/2003”). The data enteredinto the expense period data-entry field 608 may actually be the date inerror, however, rather than that entered into the expense reportdata-entry field 202. In these types of cases, the real-time validationtool 122 can mark both fields (not shown).

The real-time validation tool 122 can mark either data-entry field inthe above-disclosed manners. It can, for example, mark the report datedata-entry field 202 with a dashed red-lined box (shown in FIG. 6) andthe expense period data-entry field 608 with a solid-red-line box (notshown). The real-time validation tool 122 can also mark a data-entryfield that is invalid because invalid data has been entered into it,with a dashed red-lined box and a data entry field that is invalidbecause it does not contain any data, with a solid, red underline. Inthis implementation the real-time validation tool 122 marks thedata-entry fields differently so that the user knows quickly and easilythat each of these data-entry fields needs to be investigated, but candifferentiate between them.

For these modeless errors, the real-time validation tool 122 permits theuser to proceed, according to the block 312, discussed above.

For modal errors, however, the real-time validation tool 122 presents adialog (block 318). The user then can dismiss the dialog. Once thedialog is dismissed, the real-time validation tool 122 rolls back theinvalid entry and enables the user to continue editing the electronicform. This editing can include re-inputting data into the data-entryfield (block 320), or editing another data-entry field. Alternatively,the real-time validation tool 122 leaves the error in the document, butwill not allow the user to continue editing the document without firstcorrecting the error.

In the block 318, the real-time validation tool 122 presents an alert tonotify the user of the invalid entry. This alert is intended to informthe user that the error is important and must be fixed. It does not haveto be a pop-up window, but should be obvious enough to provide the userwith an easy-to-notice notification that the user has entered datacausing an error. The alert, in one implementation, is a pop-up windowthat requires the user to pause in editing the electronic form by makingthe user click on an “OK” button in the alert. This stops the usermentally, helping the user to notice that he must fix the data-entryfield having the error before proceeding. The alert can contain no,little, or extensive information about the error. The information can bepresented automatically or after the system 100 receives a request forthe information.

FIG. 7 shows the partially filled-in expense report 201 electronic formwith a date dialog box 702 arising from invalid data causing a modalerror. The dialog box contains a button marked “OK” that the user mustselect (a date dialog button 704). The date dialog box 702 also containsa date information line 706 informing the user about the error, “TheReport Date Must Be Later Than the Expense Period.” This information isintended to aid the user's attempt to correct the invalid data.

FIG. 8 shows another example of a dialog box used for a modal error. InFIG. 8, a nearly all-filled-in expense report 201 electronic form withan invalid number dialog box 802 is shown. This expense report 201contains many filled-in data-entry fields, each of which is not shown tobe invalid with the exception of a cost data-entry field 804. The costdata-entry field 804 contains a modal error, “a”. When the user enteredthe textual data “a”, the real-time validation tool 122 found it invalidand presented the invalid number dialog box 802. The invalid numberdialog box 802 informs the user through an invalid number informationline 806 that the data entered is not valid because it is not a numberbetween negative and positive 1.7976913486231E308. In this example it isnot a valid number because it is not a number at all. Like the priorexample, the user must select a button in the dialog box, here aninvalid number button 808.

After presenting the user with some sort of alert in block 318 (FIG. 3),the real-time validation tool enables the user to re-input data into thedata-entry field containing the modal error (block 320). Here the usermust change the data within the data-entry field to a valid or modelesserror before continuing to edit new data-entry fields in the electronicform. Once the user inputs new (or the same) data into the data-entryfield (such as the cost data-entry field 804 of FIG. 8), the system 100receives the data at the block 306 and so forth. To proceed, the usermust enter data that is not a modal error; if the user does not, thesystem 100 will follow the process 300, continuing to find the datamodally invalid and not permit the user to continue.

Through this process 300 of FIG. 3, the system 100 can receive andvalidate data in real-time. By so doing, a user can easily, accurately,and efficiently edit a structured data file through entry of data intodata-entry fields in an electronic form.

The examples set forth in FIGS. 2 and 4-8 are examples, and are notintended to be limiting on the abilities of the system 100 or thereal-time validation tool 122; other types of forms, data-entry fields,and alerts can be used.

Creating Custom Validation Rules for Structured Data Files

Overview

The system 100 of FIG. 1 includes the real-time validation tool 122,which enables a developer to create or customize validation rules for astructured data file. To enable the developer to choose a node for whichto create or customize a validation rule, the real-time validation tool122 displays nodes of a structured data file or its generalized instanceand/or the data-entry fields mapped to those nodes. A generalizedinstance is a structured data file that has been generated from a schemaand is comprehensive enough to illustrate all structural patternsallowed by the schema. Nodes in the generalized instance are a couplingof a node from a structured data file and a part of the structured datafile's schema that governs that node. (For more on nodes, see thedescription relating to FIG. 14, below.) Because the nodes of ageneralized instance for a structured data file are related to the nodesof the structured data file, nodes of the generalized instance can bechosen in place of a related node of a structured data file. Inaddition, data-entry fields that map to either of those nodes can alsobe selected in their place. In each of these cases, the real-timevalidation tool 122 recognizes the node of the structured data file towhich a validation rule should be applied.

If the electronic form is in the process of being built, the developerwill probably find it easiest to add custom validation rules whilecreating the form. Because of this, the real-time validation tool 122enables the developer to add a custom validation rule to a data-entryfield as that data-entry field is being added to the electronic form.

The real-time validation tool 122 also enables a developer to add customvalidation rules to nodes after an electronic form mapped to thestructured data file (or its generalized instance) has been created. Ineither case, the real-time validation tool 122 enables a developer toeasily create custom validation rules for nodes of a structured datafile, thereby improving a data-entry user's ability to accurately andefficiently enter data for storage in a structured data file. This isbecause when a user later enters data intended for that particular node,the real-time validation tool 122 can access the custom validation rulefor that node. Custom validation rules make editing a structured datafile more accurate and efficient.

In addition, the real-time validation tool 122 enables a developer tocreate custom validation rules in an easy-to-use way by allowing thedeveloper to choose from preset validation rules. These presetvalidation rules can be chosen quickly and easily by a developer even ifthe developer is not skilled in programming.

FIG. 9 shows a process 900 for adding validation rules for nodes in astructured data file. The process 900 is illustrated as a series ofblocks representing individual operations or acts performed by thesystem 100. The process 900 may be implemented in any suitable hardware,software, firmware, or combination thereof. In the case of software andfirmware, the process 900 represents a set of operations implemented ascomputer-executable instructions stored in memory and executable by oneor more processors.

Selecting a Node and a Preset or Script-Based Validation Rule

At block 902, the real-time validation tool 122 enables a developer toselect a node in a generalize instance or structured data file eitherdirectly or through selecting a data-entry field in an electronic formthat is associated with that node. A developer can select a node byright-clicking on it with the mouse 114, entering a command in thekeyboard 110, or in some other manner through the other device(s) 112(all of FIG. 1).

FIG. 10 shows an exemplary custom validation screen 1000, including adevelopment copy of an expense report electronic form 1002. Theelectronic form 1002 is a development copy because it is a copy that isnot intended for data entry by a user, but rather editing of its formand structure by a developer. In this example, each data-entry fieldshown in the electronic form 1002 is associated with a node in ageneralized instance and/or structured data file. The developmentelectronic form 1002 is displayed by the real-time validation tool 122to enable a developer to select a data-entry field associated with anode. By doing so, the developer can add a custom validation rule tothat node.

At block 904, the system 100 receives a selection of a node (directly orthrough selection of a data-entry field).

FIG. 10 shows an example of a node chosen by a developer. In thisexample, the developer selected a date data-entry field 1004. Oncereceived, the system 100 reacts according to block 906.

At the block 906, the system 100 enables a developer to select a presetor script-based validation rule. The system 100 can enable thedeveloper's selection through many user-interface manners, including bypresenting a pop-up window with various options, one of which includesan option to add a custom validation rule to the selected node. Thedeveloper can choose from a preset list of validation rules or canchoose to create his or her own validation rule by creating script.

FIG. 10 shows a properties box 1006, providing the developer with anoption to perform various functions, one of which includes an option tocustomize the validation rules for the selected node. By clicking on orotherwise selecting a data validation option button 1008, the developercan choose to see a validation option box, shown in FIG. 11.

FIG. 11 shows an exemplary custom validation screen 1100, including thedevelopment copy of the expense report electronic form 1002 and avalidation option box 1102 entitled “Data Validation (Date)”. In thisexample, the “(Date)” part of the title is from the name for theselected data-entry field in the electronic form 1002. This feature isintended to make it easier for the developer to keep track of the nodefor which he is adding a validation rule.

The validation option box 1102 is used to enable the developer to choosewhich type of custom validation rule to add (and/or edit, if one alreadyexists). The developer can choose to add a preset custom validation ruleby selecting an add preset rule button 1104. The developer can alsochoose to add a script-based validation rule by selecting either of twoevents in an event box 1106, OnBeforeChange event 1108 or OnValidateevent 1110. Script-based validation rules and events used in them willbe discussed in greater detail below.

At block 908, the system 100 determines whether the developer selectedan option to add a custom validation rule using preset rules orscript-based rules. If the developer chose preset rules, the system 100proceeds to block 910. If the developer chooses to create a script-basedvalidation rule, the system 100 proceeds to block 912.

Preset Validation Rules

At the block 910, the system 100 enables selection of preset rules. Thesystem 100 enables a developer to select from a list of many validationrules that are desirable for validating data. These preset validationrules can be selected by the developer in an easy, efficient manner.Also, these preset validation rules enable the developer to createpowerful validation rules for the real-time validation tool 122 to usewhen validating data. Another benefit of these preset validation rulesis that the developer does not need to know how to program or write code(script or otherwise). Also, these validation rules do not have to beexclusive, they can be added to other validation rules, such asvalidation rules based on the structured data file's schema or customscript-based validation rules. Thus, these preset validation rules canallow a developer with little or no programming ability to create abroad range of useful validation rules, making it accurate and efficientfor an eventual user to edit a structured or unstructured data file.

Many different types of preset validation rules can be made available bythe system 100. These can include rules that require data entered to beof a certain size, be numbers or text, and compare in certain ways withdata from other data-entry fields, for example. To give a developerflexibility, the preset validation rules can be adjusted by thedeveloper entering numbers or text, or relating data in one field toanother. Examples of how this can be done will be discussed in thefollowing example in FIG. 12.

FIG. 12 shows an exemplary custom validation screen 1200, including thedevelopment copy of the expense report electronic form 1002, theproperties box 1006 (obscured), the validation option box 1102(obscured), and a preset validation selection box 1202, entitled “PresetValidation (Date)”. In this example, the “(Date)” part of the title isfrom the name for the selected data-entry field in the electronic form1002. This feature is intended to make it easier for the developer tokeep track of the node for which he is adding a validation rule.

In this example, the developer chose to add a preset validation rule byselecting the add validation button 1104 of FIG. 11. Once that selectionwas received by the system 100, the system 100 presented the presetvalidation selection box 1202. In this example, the developer hasselected to add a preset validation rule and is attempting to view thedifferent options for preset validation rules. Thus, the system 100 isdisplaying a list of preset validation rules through a preset validationlist 1204 in FIG. 12.

From this list the developer can create a validation rule. The developercan choose to require (via the validation rule) that data entered intothe date data-entry field 1004 be of a certain sort. Using the presetvalidation list 1204 as an example, the developer can choose aparticular type of preset validation rule. With the preset validationrule selected, the developer can then enter text, numbers, another node,or whatever is appropriate. The developer can select a preset validationrule and then add, into a validation field 1206, numbers, text, a node,or etc., to complete the validation rule. The system 100 canintelligently aid the developer by providing appropriate options, suchas suggesting a date for the date data-entry field 1004. This is anotheraid to guide the developer, helping him or her to easily add and/or editvalidation rules.

The developer can choose from various useful preset validation rules,such as those set forth in FIG. 12 in the preset validation list 1204.This list includes preset validation rules of: “is equal to”; “is notequal to”; “is less than”; “is greater than”; “is greater than or equalto”; “is present”; “is not present”; “is blank”; “is not blank”;“contains”; “does not contain”; “begins with”; and “does not beginwith”, for example.

FIG. 13 shows an exemplary custom validation screen 1300, including thedevelopment copy of the expense report electronic form 1002, theproperties box 1006 (obscured), the validation option box 1102(obscured), the preset validation selection box 1202, and two validationfield options, enter date option 1302 and enter field option 1304.

Once a preset validation rule is selected by the developer, such as the“is equal to” preset validation rule, the developer can enter anappropriate date, such as “3/13/2003” into the enter date option field1302 or select a field with the enter field option 1304. In the presentexample, the developer does not select to enter a date, but ratherselects a data-entry field compared to which the date must be equal inorder for the data entered to be valid.

If the developer chooses to select a field (in this present example byselecting the enter field option 1304), the system 100 enables thedeveloper to choose from nodes and/or data-entry field mapped to thosenodes. The system 100 can do so simply by allowing the developer tochoose from data-entry fields shown in the electronic form or from alist of nodes in the generalized instance. Because the nodes of thegeneralized instance and the data-entry fields of the electronic formare related, choosing either the node or the data-entry field associatedwith the node can be allowed by the system 100. Some developers may beunfamiliar with nodes of a generalized instance and so may feel morecomfortable choosing from data-entry fields associated with those nodes.The developer need not know that the data-entry fields are associatedwith nodes, however. By so enabling the developer to choose in whicheverway he or she is comfortable, the system 100 improves the customizationexperience of the developer.

FIG. 14 shows an exemplary custom validation screen 1400, including thedevelopment copy of the expense report electronic form 1002, theproperties box 1006 (obscured), the validation option box 1102(obscured), the preset validation selection box 1202 (partiallyobscured), and a node selection box 1402.

Continuing the ongoing example, the developer can choose the enter fieldoption 1304 in FIG. 13. After the developer does so, the system 100presents nodes of the generalized instance or structured data file thatmap to or govern the data-entry fields in the electronic form. In thisexample, the system 100 presents nodes from the generalized instance,shown in the node selection box 1402. This enables the developer tochoose a node, such as by selecting a start date node 1404 in the nodeselection box 1402.

FIG. 14 serves to demonstrate the structured format of nodes in astructured data file, as well as the relationship between nodes anddata-entry fields. The node selection box 1402 includes a partial listof the nodes of the structured data file corresponding to the expensereport electronic form 201. These nodes include nodes mapped todata-entry fields, such as the start date node 1404, an expense codenode 1406, an end date node 1408, a report date node 1410, a purposenode 1412, and a notes node 1414. These nodes are mapped, respectively,to the expense period data-entry field 608, the expense code data-entryfield 204, an end date data-entry field 1416, the report date data-entryfield 202, a purpose data-entry field 1418, and a notes data-entry field1420. These nodes also include nodes that contain or govern other nodes,such as a manager node 1422, which governs the nodes 1404 to 1414. Thestructured aspect of the structured data file and/or generalizedinstance is shown here by nodes governing other nodes, and graphicallyby some nodes being presented in the form of a folder icon and somebeing indented related to others.

At block 914, the system 100 receives a selection of a preset rule. Thesystem 100 can receive the selection in various ways, including thoseset forth for selecting nodes and data-entry fields above. The selectionof a preset validation rule may include numerous steps, as shown in theforegoing example.

In the foregoing example, because of the developer's selection of thestart date node 1404, the system 100 adds a validation rule requiringthat data entered into the date data-entry field 1004 be equal to thedate entered or retained in the start date node. This start date node isassociated with a start date data-entry field 608, shown in FIG. 14.

Alerts for the Preset Validation Rule

At block 916, the system 100 enables the selection of alert informationfor the user. Before, after, or as part of a developer adding a presetvalidation rule, the system 100 enables the developer to add alertinformation that can be presented to the user if the user violates apreset validation rule. The developer can choose from defaultinformation or input custom information. The developer can choose howthe alerts and their information and graphics are presented, such asthrough a dialog box in a pop-up window or a line of text appearing ifthe user moves a mouse icon over the data-entry field. With or withoutinformation, the developer can choose from various graphical aspects tobe included in an alert, such as box or dashed-line box around thedata-entry field, a squiggly line under the data in the data-entryfield, shading of the data-entry field, and in other manners.

FIG. 15 shows an exemplary custom validation screen 1500, including thedevelopment copy of the expense report electronic form 1002, theproperties box 1006 (obscured), the validation option box 1102(obscured), the preset validation selection box 1202, and an informationalert option box 1502.

In the example shown in FIG. 15, the system 100 enables the developer tochoose information to be made available to the user if he enters dataviolating the associated preset validation rule. Here the developer canchoose two sets of information to be presented. The system 100 presentsthe first set of information as a “screen tip”, which arises when theuser makes the error, and can be presented automatically or if the usermoves a mouse icon or otherwise selects the data-entry field containingthe invalid data.

The system 100 presents the second set of information either at therequest of the user or automatically, depending on the preference of thedeveloper. The developer can choose to have the second set ofinformation presented automatically and in a dialog box in a pop-upwindow, for instance. The developer can choose for the dialog box tocontain a button, such as a button like the invalid number button 808 ofFIG. 8, and that the user must click to continue editing the electronicform. A developer could desire to automatically present a pop-up windowso that the user takes special attention to the invalid entry. Forerrors the developer is not as concerned about or if the developerthinks it more efficient for the user to be able to continue editing theelectronic form without the interruption of a pop-up window, thedeveloper can choose to have the information only come up at the user'srequest.

FIG. 16 shows an exemplary custom validation screen 1600, including thedevelopment copy of the expense report electronic form 1002, theproperties box 1006 (obscured), the preset validation selection box1202, and the information alert option box 1502. In this example, whichis not based on the date data-entry field 1004 of FIG. 15, a developerhas entered two messages using the information alert option box 1502.The first, entered into a screen tip field 1602, is presented to theuser as a screen tip, such as is shown in the error information 606field of FIG. 6. The second, entered into a message dialog field 1604,is presented to the user as a message in a dialog box if the userrequests, such as is shown in the date information line 706 of FIG. 7.

Associating the Preset Validation Rule with its Node

At block 920, the system 100 associates the preset validation rule andits alert information with the selected node. The system 100 associatesa preset validation rule and its alert information (and/ornon-information alert, if applicable) to the node selected for thevalidation rule by mapping the preset validation rule to the node. Thismapping can be accomplished through a declarative syntax, which caninclude XPath expressions. Each preset validation rule that governs anode, or group of nodes, can be associated with the node or group ofnodes with XPath expressions. The alert information can also beassociated with the node or nodes with XPath expressions, either aloneor along with the preset validation rule.

An example of the declarative syntax the system 100 can use to associatea preset validation rule to its node is shown below:

 <xsf:validationConstraints> <xsf:errorCondition   match=“TravelPlan”    expression=”. &gt; . . ./endDate”     expressionContext=”startDate”    showErrorOn=”.|. . ./endDate”>    <xsf:errorMessage  type=”Modeless”   shortMessage=”short error message”>           long error message        </xsf:errorMessage> </xsf:errorCondition> </xsf:validationConstraints>

In this example, a preset validation rule is associated with a node,marked as “TravelPlan”, of a structured data file. When a user laterenters data into a data-entry field mapped to this node, the real-timevalidation tool 122 can validate the data against the preset validationrule. The preset validation rule shown here is specified by the“expression” attribute and is positive (violated) when the data enteredinto a data-entry field marked “endDate” violates a condition where thedata entered previously into a “startDate” data-entry field is greaterthan the data entered into the “endDate” data-entry field. The error isshown on the “endDate” data-entry field through the code“showErrorOn=”.|../endDate“>”.

As part of this block 920, the system 100 can build a file containingthe preset validation rules created for the structured data file (or, insome cases, a generalized instance for the structured data file). Thisfile of preset validations can be added to the structured data file'ssolution. The structured data file's solution, as mentioned above,contains various files, such as a viewing file to create an electronicform.

Returning to the block 908, if a developer chooses to add a customvalidation rule using script, the system proceeds to the block 912.

Script-Based Validation Rules

At the block 912, the system 100 enables input of a script-based rule.The system 100 can enable input of a script-based rule in various ways,including easy-to-use ways like presenting a screen for inputtingscript, providing much of the surrounding script so that the developerdoes not have to write as much script, and the like. By so doing, thesystem 100 provides an easy-to-use way for a developer to inputvalidation rules.

The system 100 provides this way of adding validation rules (and relatedalert information, also through the script) for developers desiringgreater control than the preset rules allow, such as a developer wishingto add a validation rule of considerable complexity. Through script thedeveloper can, for example, add a validation rule that compares datareceived against an entry in a non-local database, such as zip-code datareceived against postal zip-code database for the United States.

In addition, through script a developer has a lot of flexibility. Scriptallows a developer to display alert messages in a pop-up window, with apassive screen tip, and in other manners. Script also allows a developerto choose what information is presented to a user and when it ispresented. A developer could, for example, have an alert message appearwhen a user enters invalid data but before the user continues on toanother data-entry field. The developer could have an alert appear onthe screen with dialog, an alarm and information presented through audio(if the system 100 connects to speakers), and/or have the data-entryfield with the invalid data highlighted in various ways. The developercould choose for the data-entry field to be highlighted with a box, adashed-line box, shading, underlining, and choose the color for each.

Script also allows a developer to set whether or not the validationrule, when violated, results in a modal or modeless error. By so doing,the real-time validation tool 122 allows the developer to create avalidation rule for a particular node of a structured data file, decidewhether it is modal or not, and create the presentation and content ofalerts.

FIG. 17 shows an exemplary custom validation screen 1700, including thedevelopment copy of the expense report electronic form 1002, the datedata-entry field 1004, the properties box 1006 (obscured), thevalidation option box 1102, the OnBeforeChange event 1108, and theOnValidate event 1110. In this example, a developer can choose to inputa script-based validation rule by selecting the OnBeforeChange event1108 or the OnValidate event 1110. Event handlers are useful inassociating script-based rules with nodes, and will be discussed ingreater detail below.

FIG. 18 shows an exemplary script entry screen 1800. In this example,the system 100 continues to enable the developer to input a script-basedvalidation rule by presenting the script entry screen 1800. To aid thedeveloper in inputting script, the system 100 provides some of thescript needed, which is shown in a script entry area 1802. By so doing,the system 100 makes it easier for the developer to input a script-basedvalidation rule.

When a developer inputs script, the script can be written to include notonly a validation rule, but also the information for alerts to a userand how those alerts are displayed.

At block 922, once the developer has input the script, the system 100receives the script. The system 100 saves the script, either alone oralong with other files in the structured data file's solution.

Associating the Script-Based Validation Rule with its Node

At block 924, the system 100 associates the script with the appropriatenode. The system can associate script-based validation rules (and theincluded alert information, if any) to a particular node through use ofevent handlers. The event handlers are stored in a file accessible bythe real-time validation tool 122, such as in the solution. An eventhandler points to script that should be executed when data entered intoa particular data-entry field is received. The event handlers can pointto the script through XPath expressions, or otherwise, so long as theevent handler informs the real-time validation tool 122 of the correctscript to execute for data received.

For example, the following declaration defines an event handler for ascript-based validation rule that the real-time validation tool 122 willapply to a “travelReport/Expenses” data-entry field in an electronicform.

  <xsf:domEventHandlers>  <xsf:domEventHandlermatch=”TravelReport/Expenses” handlerObject=”TravelExpenses” />  </xsf:domEventHandlers>

The type of event handler determines when the real-time validation tool122 executes the script. One type of event handler is executed by thereal-time validation tool 122 before the real-time validation tool 122allows the user of an electronic form to move on after entering data.The OnBeforeChange event handler 1108 is an example of this type ofevent handler. With this type of event handler, when data is entered andreceived by the real-time validation tool 122, but before the real-timevalidation tool 122 allows the user to edit another data-entry field,the real-time validation tool 122 (or the system 100) executes thescript pointed to by the event handler.

Developers can use this type of event handler for errors that thedeveloper wants to be modal. This type of event handler can be used formodal errors because the real-time validation tool 122 is able todetermine, by executing the script, that the data entered is invalidbefore it has allowed the user to continue editing the electronic form.Thus, the developer can stop the user from continuing to edit theelectronic form if the rule is violated.

Continuing the previous example, the following script is executed by thereal-time validation tool 122 whenever any change is made to the“TravelReport/Expenses” data-entry field or its node (or any other nodeinside its hierarchy) but before the real-time validation tool 122allows the user to continue editing the electronic form. Thisscript-based validation rule is violated if the data received for the“TravelReport/Expenses” data-entry field is greater than 500, based onthe script: “value of expense report !=500”. If the data received isgreater than 500, this script-based validation rule will cause thereal-time validation tool 122 to return a modal error.

 function TravelExpenses::onBeforeChange (eventObj) {   if(eventObj.Source.Text != ‘500’   {    eventObj.ReturnMessage = “Correctvalue is 500”;     return false;    }   return true;  }

Another type of event handler is executed by the real-time validationtool 122 after the real-time validation tool 122 has allowed the user ofan electronic form to move on after entering data. The OnValidate eventhandler 1110 is an example of this type of event handler. Developers canuse this type of event handler for errors that the developer desires tobe modeless. Errors that are programmatically added to the electronicform can constantly be checked by the real-time validation tool 122 andautomatically cleared when the condition that triggered them no longerexists.

A Computer System

FIG. 19 shows an exemplary computer system that can be used to implementthe processes described herein. Computer 1942 includes one or moreprocessors or processing units 1944, a system memory 1946, and a bus1948 that couples various system components including the system memory1946 to processors 1944. The bus 1948 represents one or more of any ofseveral types of bus structures, including a memory bus or memorycontroller, a peripheral bus, an accelerated graphics port, and aprocessor or local bus using any of a variety of bus architectures. Thesystem memory 1946 includes read only memory (ROM) 1950 and randomaccess memory (RAM) 1952. A basic input/output system (BIOS) 1954,containing the basic routines that help to transfer information betweenelements within computer 1942, such as during start-up, is stored in ROM1950.

Computer 1942 further includes a hard disk drive 1956 for reading fromand writing to a hard disk (not shown), a magnetic disk drive 1958 forreading from and writing to a removable magnetic disk 1960, and anoptical disk drive 1962 for reading from or writing to a removableoptical disk 1964 such as a CD ROM or other optical media. The hard diskdrive 1956, magnetic disk drive 1958, and optical disk drive 1962 areconnected to the bus 1948 by an SCSI interface 1966 or some otherappropriate interface. The drives and their associated computer-readablemedia provide nonvolatile storage of computer-readable instructions,data structures, program modules and other data for computer 1942.Although the exemplary environment described herein employs a hard disk,a removable magnetic disk 1960 and a removable optical disk 1964, itshould be appreciated by those skilled in the art that other types ofcomputer-readable media which can store data that is accessible by acomputer, such as magnetic cassettes, flash memory cards, digital videodisks, random access memories (RAMs), read only memories (ROMs), and thelike, may also be used in the exemplary operating environment.

A number of program modules may be stored on the hard disk 1956,magnetic disk 1960, optical disk 1964, ROM 1950, or RAM 1952, includingan operating system 1970, one or more application programs 1972 (such asa real-time validation tool), other program modules 1974, and programdata 1976. A user may enter commands and information into computer 1942through input devices such as a keyboard 1978 and a pointing device1980. Other input devices (not shown) may include a microphone,joystick, game pad, satellite dish, scanner, or the like. These andother input devices are connected to the processing unit 1944 through aninterface 1982 that is coupled to the bus 1948. A monitor 1984 or othertype of display device is also connected to the bus 1948 via aninterface, such as a video adapter 1986. In addition to the monitor,personal computers typically include other peripheral output devices(not shown) such as speakers and printers.

Computer 1942 commonly operates in a networked environment using logicalconnections to one or more remote computers, such as a remote computer1988. The remote computer 1988 may be another personal computer, aserver, a router, a network PC, a peer device or other common networknode, and typically includes many or all of the elements described aboverelative to computer 1942. The logical connections depicted in FIG. 19include a local area network (LAN) 1990 and a wide area network (WAN)1992. Such networking environments are commonplace in offices,enterprise-wide computer networks, intranets, and the Internet.

When used in a LAN networking environment, computer 1942 is connected tothe local network through a network interface or adapter 1994. When usedin a WAN networking environment, computer 1942 typically includes amodem 1996 or other means for establishing communications over the widearea network 1992, such as the Internet. The modem 1996, which may beinternal or external, is connected to the bus 1948 via a serial portinterface 1968. In a networked environment, program modules depictedrelative to the personal computer 1942, or portions thereof, may bestored in the remote memory storage device. It will be appreciated thatthe network connections shown are exemplary and other means ofestablishing a communications link between the computers may be used.

Generally, the data processors of computer 1942 are programmed by meansof instructions stored at different times in the variouscomputer-readable storage media of the computer. Programs and operatingsystems are typically distributed, for example, on floppy disks orCD-ROMs. From there, they are installed or loaded into the secondarymemory of a computer. At execution, they are loaded at least partiallyinto the computer's primary electronic memory. The invention describedherein includes these and other various types of computer-readablestorage media when such media contain instructions or programs forimplementing the blocks described below in conjunction with amicroprocessor or other data processor. The invention also includes thecomputer itself when programmed according to the methods and techniquesdescribed herein.

For purposes of illustration, programs and other executable programcomponents such as the operating system are illustrated herein asdiscrete blocks, although it is recognized that such programs andcomponents reside at various times in different storage components ofthe computer, and are executed by the data processor(s) of the computer.

CONCLUSION

The above-described real-time validation tool provides an easy andintuitive way for a user to correctly and efficiently edit structureddata files by notifying the user of her errors as she makes them. Theabove-described real-time validation tool also enables a developer toefficiently create custom validation rules for use by the real-timevalidation tool. Although the invention has been described in languagespecific to structural features and/or methodological acts, it is to beunderstood that the invention defined in the appended claims is notnecessarily limited to the specific features or acts described. Rather,the specific features and acts are disclosed as exemplary forms ofimplementing the claimed invention.

The invention claimed is:
 1. A system comprising: one or moreprocessors; and one or more computer-readable storage memories embodyingcomputer-readable instructions which, when executed by the one or moreprocessors, implement a validation tool configured to perform operationscomprising: presenting a user interface configured to: enable selectionof a node of a structured data file, the node being associated with aparticular data-entry field of multiple data-entry fields in anelectronic form; receive selection of the node; enable selection of apreset validation rule for the node; receive selection of the presetvalidation rule; and associating the preset validation rule with thenode; confirming data entered into each data-entry field of the multipledata-entry fields complies with an associated validation rule; andstoring data entered into each of the data-entry fields in thestructured data file responsive to confirmation that the data enteredinto each respective data-entry field complies with the associatedvalidation rule.
 2. The system of claim 1, wherein the user interface isfurther configured to: enable selection of information to be presentedif the preset validation rule is violated; and the validation tool beingconfigured to associate the information with the node.
 3. The system ofclaim 1, wherein the user interface is further configured to: enableselection of graphics to be presented if the preset validation rule isviolated; and the validation tool being configured to associate thegraphics with the node.
 4. The system of claim 1, wherein the userinterface is further configured to enable selection of the presetvalidation rule by presenting a list of validation rules.
 5. The systemof claim 1, wherein the user interface is further configured to enableselection of the preset validation rule by presenting a list ofvalidation rules, the list including a type of present validation rulerequiring data to be within a certain range.
 6. The system of claim 1,wherein the user interface is further configured to enable selection ofthe preset validation rule by presenting a list of validation rulesincluding a type of present validation rule requiring data to benumerical or textual.
 7. The system of claim 1, wherein the userinterface is further configured to enable selection of the presetvalidation rule by presenting a list of validation rules including atype of present validation rule referencing another node in the datafile.
 8. The system of claim 1, wherein the user interface is furtherconfigured to enable selection of the node by presenting an iconrepresenting the node of the data file.
 9. The system of claim 1,wherein the user interface is further configured to enable selection ofthe node by presenting a data-entry field associated with the node ofthe data file.
 10. One or more computer-readable storage memory devicesembodying computer-readable instructions which, when executed, implementa system comprising: a validation tool having a user interfaceconfigured to: enable selection of a node of a structured data file, thenode being associated with a particular data-entry field of multipledata entry fields in an electronic form; receive selection of the node;enable input of a validation rule for the node; receive the validationrule; and the validation tool being configured to associate thevalidation rule with the node, the receipt of a validation rule for eachof the multiple data-entry fields causing each respective validationrule to be confirmed when data is entered into the data-entry fieldbefore the data is stored in the structured data file.
 11. The one ormore computer-readable storage memory devices of claim 10, wherein theuser interface is configured to enable selection of the node bypresenting an icon representing the node of the data file.
 12. The oneor more computer-readable storage memory devices of claim 10, whereinthe user interface is configured to enable selection of the node bypresenting a data-entry field associated with the node of the data file.13. The one or more computer-readable storage memory devices of claim10, wherein the user interface is configured to enable input of thescript-based validation rule by presenting a pre-constructed frameworkof script related to the node.
 14. One or more computer-readable storagememory devices embodying instructions which, when executed, implement auser interface comprising: an electronic form containing data-entryfields; an interface to enable a developer to select a data-entry fieldassociated with a node of a structured data file; and a validationscreen containing validation options for the selected data-entry field,wherein the validation options enable selection of a preset validationrule and a script-based validation rule, wherein the interface enablesthe developer to select both a preset validation rule and a script-basedvalidation rule, the selection of a preset validation rule or ascript-based validation rule causing each respective rule to beconfirmed when data is entered into the data-entry field before the datais stored in the structured data file.
 15. The one or morecomputer-readable storage memory devices of claim 14, wherein the userinterface further comprises: an event area to enable the developer toselect when the script-based validation rule will be used to validatedata by a real-time validation tool.
 16. The one or morecomputer-readable storage memory devices of claim 14, wherein the userinterface further comprises: a script entry area to enable the developerto input the script-based validation rule.
 17. The one or morecomputer-readable storage memory devices of claim 14, wherein thevalidation options include a list of preset validation rules.
 18. Theone or more computer-readable storage memory devices of claim 17,wherein the validation options include a validation field to enable thedeveloper to input criteria for the selected preset validation rule. 19.The one or more computer-readable storage memory devices of claim 18,wherein the user interface further comprises: an information alertoption area including one or more fields to enable the developer toinput alert information for the preset validation rule selected from thevalidation options.